Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d7/ker301ex.arc/MSVIBM.PIF

Text File | 1990-07-19 | 6KB | 103 lines

COMMENTS ON RUNNING KERMIT 3.0 FOR THE IBM PC UNDER MICROSOFT WINDOWS

Kermit 3.00 will successfully run in a window with Microsoft Windows and
will accept cut and pasted information.     Scripts and phone dialing instructions
are cases of cut and paste replacing the keyboard.  Use the PIFEDIT program to
construct a .PIF file for Kermit, following the guidelines below.

Program name:        KERMIT.EXE or whatever is the name of the Kermit file.
Program title:        MS-DOS Kermit 3.0
Program parameters:    Leave blank since this becomes a command line
Initial directory:    Directory, if any, to CD to when starting Kermit
Memory Requirements:    175 KB Required, xxx KB Desired (see below)
Directly Modifies:    Clear all boxes (pretend Kermit is very good)
Program Switch:        Check the Text box
Screen Exchange:    Check the Graphics/Text box
Close Window on exit:    Check the box

Comments.  Although Kermit does direct writes to the screen it does so in a
"TopView aware" manner.     One may check or leave empty the COM1 or COM2 boxes
even though Kermit does directly modify the serial port.  Kermit will block
(XOFF) if left running as an icon, but it will run smoothly while sharing the
screen with other tasks.  Communications throughput is limited by Windows'
character drawing speed.  Graphics are done as if you had a monochrome
adapter.  Screen dumps ( ^] F or Control End) will be of Kermit's underlying
full screen.  In summary, tell Windows that Kermit is exceptionally well
behaved.

If you check the modifies memory box or some of the other boxes (or if you
don't have a KERMIT.PIF file at all), then Kermit will take over the whole
screen and Windows will become inactive, and Windows features will no longer
work.  But Kermit will run much faster, and graphics will work normally.

If Windows complains that it does not have enough memory to run Kermit,
then you can reduce Kermit's memory requirements by allocating less memory for
rollback screens.  Kermit's default number of rollback screens is 10, and each
rollback screen takes about 8K of memory (more or less depending on the type
of display adapter you have).  With the default 10 rollback screens, Kermit
needs about 175K of memory.  You can reduce this to about 100K by getting rid
of some or all of your rollback screens; if you put a line like SET
KERMIT=ROLLBACK 5 in your AUTOEXEC.BAT file, this tells Kermit how many
screens to get memory for.  If you specify 0, this will reduce Kermit's memory
requirements by about 80K.

Note: problems have been reported running Kermit under Windows/286 when memory
is tight.  There have been allegations that Windows fails to observe proper
etiquette, and destroys portions of memory that Kermit has dynamically
allocated from DOS, for example for macro definitions.

------------------------------

Date: Thu, 13 Apr 1989 23:00:26 EDT
From: "Joe R. Doupnik" <[e-mail]>
Subject: MS Kermit and MS Windows

I just ran MS Kermit 2.32/A and the prerelease of Kermit 3.0 under Windows
2.03 and the 386 rendition of 2.03, both with no problems. I made Kermit a
client talking to a remote server and launched a large file GET. Then I
brought up various Windows programs such as Clock, PIFedit, Write, etc and
played about. The transfer proceeded as smoothly as Windows permits (I could
watch the Server's screen). Baud rate was 9600 and the throughput under
regular 2.03 was around 7000 and under 386 about 2800 (more games being done
and the Windows scheduler is different, 8800 with sliding windows and less
mucking about).

The PIF files had these boxes checked:

Regular Windows 2.03: Memory req'd 150KB, desired 150KB
        Program switch  Text
        Screen switch    Text
        Close window on exit
        (No COM boxes checked, pretend v. good behavior)

Windows/386:    Memory req'd 150KB, desired 150KB
        Screen mode Full Screen   Background  (also ok as just Backgnd)
        Close window on exit


I pushed poor Kermit into the background, plopped other windows on it, resized
its window, and generally behaved obnoxously. The only time Kermit stopped was
when it was forced to become an icon under regular Windows; that is normal for
regular Windows. I checked the Full Screen box in 386 mode to see what happens:
nothing untoward at all. Windows is a little awkward in that situation because
the user has to type ALT-ESCape to regain attention of the master control
program and hence invoke other tasks. Kermit ran ok even when it did not have
the "input focus" (ownership of keyboard and cursor) or was invisible.

If a second program grabs the serial port then naturally Kermit will halt.
Interpreted BASIC and older MS Compiled BASIC programs do such grabbing, and
forget to return interrupts. Some "integrated" systems programs also have
communications options which might grab the serial port. If the user has a bus
mouse then all bets are off because of the well known major problems related to
their high interrupt rates. If the second program has mouse support and that
code attempts to find a serial mouse by probing the serial ports then the baud
rate could be upset.

If people have problems running MS-Kermit under Windows, find out what
"second" programs they were running, the kind of MS Windows, kind of mouse
(serial, bus, mfr).  And of course watch out for Terminate-and-Stay-Resident
programs that might be interfering with Kermit's interrupts, and for the old
Basic programs that let the serial port interrupt point to never-never land.

End of File MSVIBM.PIF